-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Avoid calling deprecated ODBC functions #17556
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
I'm wondering when That said, individual drivers might not support all the functionality, but if we're building against a driver manager as we should, it should handle that for us. |
Yeah, I think pursuing #15630/#15727 is overdue. And I've noticed that the ODBC cursor library is deprecated ( |
`SQLGetConnectOption`, `SQLSetConnectOption` and `SQLSetStmtOption` are deprecated, so if ODBC 3 is available, we use `SQLSetConnectAttr`, `SQLGetConnectAttr`, and `SQLSetStmtAttr` instead.
743bec7
to
072062e
Compare
`SQLGetConnectOption`, `SQLSetConnectOption` and `SQLSetStmtOption` are deprecated, so if ODBC 3 is available, we use `SQLSetConnectAttr`, `SQLGetConnectAttr`, and `SQLSetStmtAttr` instead. (This is based on phpGH-17556, but just assumes ODBC 3.x.)
`SQLGetConnectOption`, `SQLSetConnectOption` and `SQLSetStmtOption` are deprecated, so if ODBC 3 is available, we use `SQLSetConnectAttr`, `SQLGetConnectAttr`, and `SQLSetStmtAttr` instead. (This is based on phpGH-17556, but just assumes ODBC 3.x.)
`SQLGetConnectOption`, `SQLSetConnectOption` and `SQLSetStmtOption` are deprecated, so if ODBC 3 is available, we use `SQLSetConnectAttr`, `SQLGetConnectAttr`, and `SQLSetStmtAttr` instead. (This is based on phpGH-17556, but just assumes ODBC 3.x.)
* Remove references to ODBCVER and assume ODBC 3.x See https://wiki.php.net/rfc/deprecations_php_8_5#remove_support_for_older_odbc_versions * Avoid calling deprecated ODBC functions `SQLGetConnectOption`, `SQLSetConnectOption` and `SQLSetStmtOption` are deprecated, so if ODBC 3 is available, we use `SQLSetConnectAttr`, `SQLGetConnectAttr`, and `SQLSetStmtAttr` instead. (This is based on GH-17556, but just assumes ODBC 3.x.) * Remove wrappers for SQLColAttribute We don't need to support the old way of doing it. * Just call SQLAllocHandle directly Again, no need for the version specific wrapper * Update NEWS for ODBCVER in beta2 * [skip ci] UPGRADING for ODBCVER changes --------- Co-authored-by: Christoph M. Becker <cmbecker69@gmx.de>
SQLGetConnectOption
,SQLSetConnectOption
andSQLSetStmtOption
are deprecated, so if ODBC 3 is available, we useSQLSetConnectAttr
,SQLGetConnectAttr
, andSQLSetStmtAttr
instead.I'm not quite sure how to actually handle this best. Assuming that we won't require ODBC >= 3, some of the error messages would need to be adapted (e.g. we should not report an issue with
SQLConnectOption
, when we actually calledSQLSetConnectAttr
. Furthermore, the generic replacement inodbc_setoption()
might be too presumptious (from looking at sqlext.h, it seems to be okay, but who knows). Possibly, we should deprecate this PHP function altogether (at least the docs could need some update).¯\(ツ)/¯
A possible alternative to the PR as is would be to introduce general shims as macros, but this might cause even more confusion.
Anyhow, we should have a look at the double casts
(SQLPOINTER) (intptr_t)
(without, Clang 18.1.8 complains); we should probably use integer types which have the same size as a pointer in the first place.